An ICN network is a conceptualization of a networking protocol stack, in particular layers 3 and above of a network protocol stack. The CCN network as well as similar networks like named data networking (NDN) networks are particular architectures and implementations of an ICN network. ICN, CCN, and NDN networks are based on the premise of naming resources in these networks. In particular, the naming relates to the use of a globally shared namespace for objects that allows entities in these networks to retrieve any content of interest. NDN networks and CCN networks have similar architectures, and for sake of clarity, examples related to CCN networks are discussed herein below.
Thus, within a CCN network, a name is utilized to identify a content object instead of an Internet Protocol (IP) address of the host of the content. In an IP network, routing is based on host names (e.g., source and destination addresses). In a CCN network by contrast, routing is based on a uniform resource identifier (URI) or similar identifier for a content object referred to as a CCN Name. CCN routing is performed hop-by-hop, using longest prefix matching on the CCN Name. All communications seeking to access data are framed as a request and response transaction. A CCN client (e.g., executed by user equipment) sends a message referred to herein as a CCN request to the nodes in the CCN network. The nodes of the CCN network respond with a CCN reply including a content object identified by a content object name in the CCN request also referred to as a CCN interest. The content object name can be a part of the CCN Name that also includes prefixes that provide a path to the content object. These content objects are returned via a CCN reply.
All content object packets are cryptographically signed by their initial provider. A CCN client can thus verify the integrity and authenticity of the content even if the packet comes from untrusted links or untrusted hosts. As a direct effect, CCN nodes in the CCN network are allowed to cache packets locally in a table called the content store. When a CCN node receives a CCN request, the CCN node can check whether its local content store has the requested content object and, if so, can send the content object to the requesting CCN client. The lookup in the content store is by the content object name. If the content object name is not found in the local content store, then the CCN request is forwarded according to entries for the content object name in a forwarding information base (FIB) of the CCN node.
The content object names and sometimes the CCN Names that identify the content objects are typically set by the original provider such as the content server. The routable prefixes that are joined with the content object names to form the CCN Names can be decided by a third party similar to the domain name service (DNS) system. However, the CCN Name is readable by anyone able to listen on the underlying links, whether the payloads of the packets of the CCN request and CCN reply are encrypted or not. This is different from tunnels in an IP context (e.g., IPsec and TLS) where the endpoints are readable by everyone, but the contents including for example hypertext transfer protocol (HTTP) URIs are not readable.